LibreOffice 24.8 est disponible, une « version majeure »

LibreOffice est désormais disponible en version 24.8, après la 24.2 et la 7.6. Alors non, The Document Foundation n’a pas débauché le responsable des numéros de versions de Microsoft, mais utilise désormais une numérotation sous la forme aa.m (années et mois), un peu à la manière d’Ubuntu. 24.8 signifie simplement qu’elle a été mise en ligne en aout 2024.

La 24.8 est donc une version majeure, contrairement à ce que son numéro de version pourrait laisser penser. Le communiqué de presse et les notes de versions ne laissent d’ailleurs pas de doute à ce sujet, avec des nouveautés aussi bien sur Writer, Calc, Impress, Draw, Chart, etc.

Pour le téléchargement, c’est par là que ça se passe. Libre Office nécessite Windows 7 SP1 minimum… « Cela ne signifie pas que The Document Foundation suggère l'utilisation de ce système d'exploitation, qui n'est plus pris en charge par Microsoft lui-même, et ne doit donc pas être utilisé pour des raisons de sécurité », ajoute l’éditeur. Chez Apple, il faut au moins MacOS 10.15.

Commentaires (17)


Alors non, The Document Foundation n’a pas débauché le responsable des numéros de versions de Microsoft


Roh, depuis quand l'équipe troll gratuitement Microsoft dans une brève :mdr: :troll:
Pour compléter, ce système de nommage de versions s'appelle Calendar Versioning ou CalVer, ce qui constitue en soi une véritable offrande aux amateurices de jeux de mots.

Moins connu ou utilisé que SemVer, cela reste une convention largement supportée par de nombreux gestionnaires de packages/dépendances.

CalVer est un format que je trouve peu intéressant, beaucoup trop variable dans son implémentation et qui ne dit rien d'intéressant par rapport au logiciel à part sa supposée date de sortie. SemVer, par contre est bien plus structuré et bien plus pratique pour déterminer le type d’évolution entre deux versions.

CalVer est certes plus plaisant pour les utilisateurs lambda d'un point de vue cosmétique, mais ça s'arrète trop souvent là... c'est peu utile pour gérer les dépendances et gérer son risque sur les dépendances.

En plus sur la page du standard ils osent dire "CalVer is a versioning convention based on your project's release calendar, instead of arbitrary numbers." ... comme si on mettait des chiffres au pif avec semver...

C'est d'ailleurs pour ça que de nombreux projets n'utilisent pas juste CalVer tel quel mais font des hybrides avec semver...

Mais bon, quand tout le monde fait des altérations ad-hoc au standard pour le rendre utilisable, c'est que ce n'est pas vraiment un standard.

ragoutoutou

CalVer est un format que je trouve peu intéressant, beaucoup trop variable dans son implémentation et qui ne dit rien d'intéressant par rapport au logiciel à part sa supposée date de sortie. SemVer, par contre est bien plus structuré et bien plus pratique pour déterminer le type d’évolution entre deux versions.

CalVer est certes plus plaisant pour les utilisateurs lambda d'un point de vue cosmétique, mais ça s'arrète trop souvent là... c'est peu utile pour gérer les dépendances et gérer son risque sur les dépendances.

En plus sur la page du standard ils osent dire "CalVer is a versioning convention based on your project's release calendar, instead of arbitrary numbers." ... comme si on mettait des chiffres au pif avec semver...

C'est d'ailleurs pour ça que de nombreux projets n'utilisent pas juste CalVer tel quel mais font des hybrides avec semver...

Mais bon, quand tout le monde fait des altérations ad-hoc au standard pour le rendre utilisable, c'est que ce n'est pas vraiment un standard.

Le versioning par date est intéressant dans le cas d'un produit en rolling release dont la version moins un est mécaniquement remplacée par la nouvelle. Et donc qu'il n'y a qu'une seule branche de release maintenue.
Exemple chez Arch Linux, et encore plus visible sur sa dérivée Manjaro dont la version est aussi du CalVer (sans être un calvaire), actuellement 24.0.7.

Dans le cas d'un produit supportant plusieurs versions simultanées, le SemVer reste plus signifiant, notamment pour les breaking changes. Et ça le CalVer est moins adapté pour ce point à moins de bien lire les release notes. Là où en SemVer on ne s'attend pas - en principe - à avoir du breaking change sur un patch ou de l'intermédiaire.
Modifié le 23/08/2024 à 13h23

Historique des modifications :

Posté le 23/08/2024 à 13h21


Le versioning par date est intéressant dans le cas d'un produit en rolling release dont la version moins un est mécaniquement remplacée par la nouvelle. Et donc qu'il n'y a qu'une seule branche de release maintenue.
Exemple chez Arch Linux, et encore plus visible sur sa dérivée Manjaro dont la version est aussi du CalVer (sans être un calvaire).

Dans le cas d'un produit supportant plusieurs versions simultanées, le SemVer reste plus signifiant, notamment pour les breaking changes. Et ça le CalVer est moins adapté pour ce point à moins de bien lire les release notes. Là où en SemVer on ne s'attend pas - en principe - à avoir du breaking change sur un patch ou de l'intermédiaire.

ragoutoutou

CalVer est un format que je trouve peu intéressant, beaucoup trop variable dans son implémentation et qui ne dit rien d'intéressant par rapport au logiciel à part sa supposée date de sortie. SemVer, par contre est bien plus structuré et bien plus pratique pour déterminer le type d’évolution entre deux versions.

CalVer est certes plus plaisant pour les utilisateurs lambda d'un point de vue cosmétique, mais ça s'arrète trop souvent là... c'est peu utile pour gérer les dépendances et gérer son risque sur les dépendances.

En plus sur la page du standard ils osent dire "CalVer is a versioning convention based on your project's release calendar, instead of arbitrary numbers." ... comme si on mettait des chiffres au pif avec semver...

C'est d'ailleurs pour ça que de nombreux projets n'utilisent pas juste CalVer tel quel mais font des hybrides avec semver...

Mais bon, quand tout le monde fait des altérations ad-hoc au standard pour le rendre utilisable, c'est que ce n'est pas vraiment un standard.

inutile pour le libre, mais pour une entreprise avec un gros marketing et des gros sousous, passer de 23.12 à 24.08 est plus sexy que de passer de 3.0.1 à 3.0.2 :pastaper:

Albirew

inutile pour le libre, mais pour une entreprise avec un gros marketing et des gros sousous, passer de 23.12 à 24.08 est plus sexy que de passer de 3.0.1 à 3.0.2 :pastaper:
Même plus.

Franchement, à part les OS plus personne se préoccupent vraiment des numéros de version. Surtout depuis que le SaaS a pris le relai des modèles économiques, il n'a d'ailleurs pas toujours intérêt à ce qu'on suive trop la qualité et la fréquence des innovations qui doivent justifier le prix 😁

MisterDams

Même plus.

Franchement, à part les OS plus personne se préoccupent vraiment des numéros de version. Surtout depuis que le SaaS a pris le relai des modèles économiques, il n'a d'ailleurs pas toujours intérêt à ce qu'on suive trop la qualité et la fréquence des innovations qui doivent justifier le prix 😁
Franchement, à part les OS plus personne se préoccupent vraiment des numéros de version.


Complètement. C'est une info de techos, le consommateur s'en fout.

Le numéro de version est loin de faire partir d'une stratégie marketing. Sauf dans le cas où il fait partie de la désignation commerciale du produit, comme Windows 11. Mais ici on parle de mouture majeure. Le client en a rien à cirer de savoir que c'est en réalité Windows 11 23H2 22631.4037 ou que son driver Nvidia est en version 150.12.

Ces éléments n'ont d'utilité que pour du support technique qui va généralement se limiter à : "vous avez installé la dernière version ?".
Modifié le 23/08/2024 à 16h34

Historique des modifications :

Posté le 23/08/2024 à 16h34


Franchement, à part les OS plus personne se préoccupent vraiment des numéros de version.


Complètement. C'est une info de techos, le consommateur s'en fout.

Le numéro de version est loin de faire partir d'une stratégie marketing. Sauf dans le cas où il fait partie de la désignation commerciale du produit, comme Windows 11. Mais le client en a rien à cirer de savoir que c'est en réalité Windows 11 23H2 22631.4037 ou que son driver Nvidia est en version 150.12.

Ces éléments n'ont d'utilité que pour du support technique qui va généralement se limiter à : "vous avez installé la dernière version ?".

SebGF

Franchement, à part les OS plus personne se préoccupent vraiment des numéros de version.


Complètement. C'est une info de techos, le consommateur s'en fout.

Le numéro de version est loin de faire partir d'une stratégie marketing. Sauf dans le cas où il fait partie de la désignation commerciale du produit, comme Windows 11. Mais ici on parle de mouture majeure. Le client en a rien à cirer de savoir que c'est en réalité Windows 11 23H2 22631.4037 ou que son driver Nvidia est en version 150.12.

Ces éléments n'ont d'utilité que pour du support technique qui va généralement se limiter à : "vous avez installé la dernière version ?".
Du moment qu'il joue son rôle de firewall ....

Timanu69

Du moment qu'il joue son rôle de firewall ....
nan, tu confonds avec OpenOffice :p

Timanu69

Du moment qu'il joue son rôle de firewall ....
J'utilise un système plus sécurisé :
- Parefeu avec le bloc note
- Control parental avec la calculatrice
- Anti crypto (aussi bien pour une rançon que du bitcoin) avec paint

Et ça marche, aucune infection aujourd'hui !:incline:

Albirew

inutile pour le libre, mais pour une entreprise avec un gros marketing et des gros sousous, passer de 23.12 à 24.08 est plus sexy que de passer de 3.0.1 à 3.0.2 :pastaper:
pas que pour le libre, pour tout développement dans des environnements microservices, il vaut mieux faire du semver si on veut fonctionner correctement.
j'aurais tellement adoré l'intégration de deux énormes fonctionnalités :
-les onglets sous libreoffice (ibm symphony le faisait)
-la collaboration via xmpp (abiword sous linux le permet)
La numérotation sémantique, c'est un standard qui permet justement de donner un sens fonctionnel aux versions et de pouvoir différencier majeure, mineures & patchs, ce qui a un intérêt pour l'utilisateur dans sa gestion de versions, en fonction du risque de bris adossé à chaque type.

Pourquoi inventer des numérotations qui n'apportent aucune information fonctionnelle pour l'utilisateur ?
Modifié le 24/08/2024 à 21h15

Historique des modifications :

Posté le 24/08/2024 à 21h14


La numérotation sémantique, c'est un standard qui permet justement de donner un sens fonctionnel aux versions et de pouvoir différencier majeure, mineures & patchs, ce qui a un intérêt pour l'utilisateur dans sa gestion de versions, en fonction du risque de bris adossé à chaque type.

Pourquoi inventer des numérotations qui n'apportent aucune information ?
Quelle différence entre utiliser le format décrit dans l'article et un entier seul qui s'incrémenterait ?

Posté le 24/08/2024 à 21h15


La numérotation sémantique, c'est un standard qui permet justement de donner un sens fonctionnel aux versions et de pouvoir différencier majeure, mineures & patchs, ce qui a un intérêt pour l'utilisateur dans sa gestion de versions, en fonction du risque de bris adossé à chaque type.

Pourquoi inventer des numérotations qui n'apportent aucune information fonctionnelle pour l'utilisateur ?
Quelle différence entre utiliser le format décrit dans l'article et un entier seul qui s'incrémenterait ?

Posté le 24/08/2024 à 21h15


La numérotation sémantique, c'est un standard qui permet justement de donner un sens fonctionnel aux versions et de pouvoir différencier majeure, mineures & patchs, ce qui a un intérêt pour l'utilisateur dans sa gestion de versions, en fonction du risque de bris adossé à chaque type.

Pourquoi inventer des numérotations qui n'apportent aucune information fonctionnelle pour l'utilisateur ?
Par là-même, quelle différence entre utiliser le format décrit dans l'article et un entier seul qui s'incrémenterait ?

De mon côté, je suis aussi pour la version sémantique (que je trouve plus utile).

La seule utilité que je trouve à la numérotation CalVer : l'utilisateur peut s'avoir si le programme est plus ou moins à jour : utiliser une version 2019.3 d'un programme donne plus d'indication que juste 15.3 par exemple.

Mais pour moi, ça s'arrête là.
Modifié le 24/08/2024 à 21h34

Historique des modifications :

Posté le 24/08/2024 à 21h34


De mon côté, je suis aussi pour la version sémantique (que je trouve plus utile).

La seule utilité que je trouve à numérotation CalVer : l'utilisateur peut s'avoir si le programme est plus ou moins à jour : utiliser une version 2019.3 d'un programme donne plus d'indication que juste 15.3 par exemple.

Mais pour moi, ça s'arrête là.

fdorin

De mon côté, je suis aussi pour la version sémantique (que je trouve plus utile).

La seule utilité que je trouve à la numérotation CalVer : l'utilisateur peut s'avoir si le programme est plus ou moins à jour : utiliser une version 2019.3 d'un programme donne plus d'indication que juste 15.3 par exemple.

Mais pour moi, ça s'arrête là.
Comme je disais en #2.2 le CalVer a un intérêt pour le rolling release quand la précédente version est supplantée par la nouvelle. Perso je l'utilisais pour des packages dont le contenu était un annule et remplace du précédent (des scripts de plan batch par exemple), on considérait donc que la dernière (build avec la date du jour) faisait autorité.

Pour les paquets qui devaient gérer de la rétrocompatibilité et de l'interdépendance, on utilisait du SemVer.

Mais après réflexion, elle a aussi un intérêt quand on maintient plusieurs branches de releases, comme Ubuntu qui a plusieurs version simultanées supportées. Typiquement dans leur cas, on sait même rapidement la date de fin de vie puisqu'il suffit de l'additionner avec la durée de support.

Bref, comme d'hab, il faut utiliser les outils adaptés et savoir se remettre en question quand ils ne le sont pas. La religion, ça fait juste chier et perdre du temps.
Pour faire joli... j'ai un de mes clients où tout le dev interne tourne autour d'un système de version trouvé sur wish, un peu du genre calver... et c'en est un. Pas moyen d'orchestrer des tests sur base des versions, tu ne sais jamais si ta release microservice budget "dynamique-2408" pose des changements cassant la compatibilité avec le microservice contrat "dynamique-2310" du composant xyz, en gros l'équipe en charge de la gestion des releases, ça doit être des fous furieux masochistes et passablement incultes qui ont p^référé imposer une signalétique pourrie pour rassurer les managers plutôt que d'avoir des versions expressives permettant de réduire le risque.
Modifié le 24/08/2024 à 21h46

Historique des modifications :

Posté le 24/08/2024 à 21h43


Pour faire joli... j'ai un de mes clients où tout le dev interne tourne autour d'un système de version trouvé sur wish, un peu du genre calver... et c'en est un. Pas moyen d'orchestrer des tests sur base des versions, tu ne sais jamais si ta release microservice budget "dynamique-2408" pose des changements cassant la compatibilité avec le microservice contrat "dynamique-2310" du composant xyz, en gros l'équipe en charge de la gestion des releases, ça doit être des fous furieux masochistes et passablement incultes qui ont p^référé imposer une signalétique pourrie pour rassurer les managers plutôt que d'avoir des versions expressives permettant de réduire le risque.

Pour info le changement de schéma de numérotation des versions a été annoncé il y a un an lors de la publication de la version 7.6. Cela avait été signalé par Next en février lors de la publication de la version 24.2.

Cela dit, en ce qui concerne LibreOffice, le changement de schéma de numérotation de version est seulement une affaire de communication pour aider l'utilisateur final à mieux situer les versions puisque leur numéro ne change plus de façon arbitraire. De plus ce changement de schéma de numérotation n'a que très peu d'impact technique. Par exemple pour la recherche d'une nouvelle version le système n'utilise pas le numéro de version mais l'identifiant de commit (disponible également dans la boîte de dialogue "À propos de LIbreOffice".
Autrement dit il est facile de comprendre qu'il y a 2 ans et demi d'évolution entre la version 24.2 et la version 26.8, alors que ce qui séparerait les versions 7.7 et 8.4 c'est bien plus obscur.
Fermer